前言

今天來稍微講點輕鬆的內容，但同時也是 K8s 中非常重要的一個觀念，從這篇文章開始都會是 Pod 的擴充內容，但在正式進入擴充內容之前先帶大家了解一下一個非常重要的觀念：Stateless 與 Stateful 。

什麼是 Stateless？

Stateless 顧名思義就是無狀態，簡單來說就是我們每次跟伺服器要資料的過程中都不會被伺服器記錄狀態，每次 Request 都是獨立，彼此是沒有關聯性的，也就是說我們每次獲得的資料僅限於當下有用因為無法保存，所以靜態網頁通常都是一種 Stateless 應用。

舉例來說：今天想到氣象局查看天氣，我可以藉由 Google 搜尋氣象局並點擊連結，或者是直接在瀏覽器輸入 https://www.cwb.gov.tw/V8/C/ ，這兩種最終結果都會一致，並不會因為我任何的操作而產生不同的結果，這就是一種 Stateless 的表現。

什麼是 Stateful？

tateful 就是 Stateless 的相反，也就是每次的 Request 都會被記錄下來，日後都還是可以進行存取，而 Stateful 最常見的就是資料庫，所以我們可以想像 Stateful 應用背後一定會有一個負責更新內容的儲存空間。

舉例來說：今天想到 Google 雲端硬碟查看內容，我必須要先登入自己的 Google 帳號才可以查看內容，這種會有操作先後順序才會有結果的就是一種 Stateful 的表現。

為什麼要提到 Stateless 以及 Stateful 呢？

其實跟我們 Pod 有很大的關係，在 K8s 中 Pod 是屬於 Stateless 的，前面提到 Stateless 的特性就是每次 Request 都是獨立的，這樣有一個最大的好處就是可以快速擴充。

在 Pod 的文章中提到：Pod 是 K8s 中可以運行的最小單位，由於 Pod 是屬於 Stateless 的，即便今天同一種內容的 Pod 有多個也沒關係，因為每次的 Request 都是獨立的，多個 Pod 就多個連線的端點而已，所以這也是為什麼 Pod 會是 Stateless ，至於要如何擴充 Pod 筆者會在後續的文章說明。

K8s 的 Stateful

上面提到由於 Pod 本身是 Stateless 了再加上 Pod 也是 K8s 的最小運行單位，難道 K8s 就沒辦法做 Stateful 應用嗎？其實是可以的，K8s 為了 Stateful 有特別開啟一種類別叫： StatefulSet。

由於 K8s 的 StatefulSet 牽涉到非常多進階的觀念，這些都是前面文章沒有提過的，所以這裡筆者就先提一下 K8s 的 StatefulSet 架構，範例的部分讀者可以參考官網的範例。

StatefulSet 架構

StatefulSet 一共有兩個重要的部分：

• Persistent Volume Claim

  前面提到 Stateful 背後會有一個更新內容的儲存空間，在 K8s 中負責管理儲存空間的就是 Volume ，作用跟 Docker 的 Volume 幾乎一模一樣，但畢竟 K8s 的 Volume 只是在 Pod 中做暫時存放的儲存空間而已，當 Pod 移除之後這個儲存空間也會一併消失，為了要在 K8s 中建立一個像資料庫可以永久儲存的空間，也就是這個 Volume 不能被包含在 Pod 內，而這個就是 Persistent Volume。

  Persistent Volume Claim 就是負責連接 Persistent Volume 的物件了，所以可以想像一下今天有多少的 Persistent Volume 就會有多少個 Persistent Volume Claim ，這兩個是相輔相成的。

• Headless Service

  還記得在 Service 的文章中提到 ClusterIP 嗎？其實每個 Service 都會有一組自己的 ClusterIP (ExternalName 形式的除外)，所以 Headless 的意思其實就是不要有 ClusterIP，方法也很簡單直接在設定檔裡面加個 ClusterIP: None 即可。

  這麼做有什麼好處呢？由於 Headless Service 並沒有直接跟 Pod 有對應關係，因此 Service 本身沒有 ClusterIP ，所以 K8s 內部在溝通時就沒辦法把我們設定好的 Service 名稱進行 IP 轉換，不過 Headless Service 會將內部的 Pod 都建立一個專屬於自己的 domain ，所以我們可以自由的選擇要連接到某個 Pod，至於 K8s 內部是如何溝通的筆者之後也會寫一篇文章介紹給大家，這裡讀者稍微有個印象就好。

  這時候你可能會想說我也可以自己手動連接啊？但因為 Service 一般是跟著 Pod 的 Label 走，所以一個 Service 會連接到許多個 Pod ，這樣我們就沒辦法針對其中一個 Pod 做事情了，所以 Headless Service 在 StatefulSet 中也會被建立就是這個原因，不過這個也是要看架構師要如何設計這塊就是了。

還記得筆者一直有強調 K8s 中最小的執行單位是 Pod ，即便是 StatefulSet 也會有 Pod ，只是這個 Pod 會歸 StatefulSet 管，綜合上面所提到的可以知道一個 StatefulSet 裡面除了執行的 Pod 外還會有負責跟 Persistent Volume 連接的 Persistent Volume Claim，所以整體 StatefulSet 的架構會長得像下面這樣。

小結

今天介紹了 Stateless 以及 Stateful 兩個滿重要的觀念，但這裡筆者稍微埋了個伏筆，到底 StatefulSet 是如何控制底下的 Pod 呢？

所以從下一篇文章開始要介紹給各位讀者 K8s 是如何控管底下 Pod 數量，如果對於文章有任何問題都歡迎留言給我，那我們就下一篇文章見嘍～